The 3rd Generation Partnership Project (3GPP) has developed specifications for MBMS, which provides broadcast and multicast services over radio networks. With the development of the mobile devices' capability of consuming multimedia content and the deployment of wideband radio networks, MBMS are becoming widely spread. The Long Term Evolution (LTE) has introduced evolved MBMS (eMBMS) to deliver multimedia data from a single source entity to multiple destinations in LTE. A description of the MBMS system architecture and functionality is given in 3GPP TS 23.246, v11.1.0, March 2012.
FIG. 1 illustrates the logical architecture of eMBMS, which is described in further detail in 3GPP TS 36.300, v11.6.0, July 2013.
The MBMS-specific components in FIG. 1 include an MBMS Gateway (MBMS GW) 110 and a Multicast Coordination Entity (MCE) 130. The MSMS GW 110 is connected to eNodeB(s) 140 via an M1 interface and connected to a Broadcast Multicast-Service Center (BM-SC) 150 via SGmb and SGi-mb interfaces. The MCE 130 is connected to eNodeB(s) 140 via an M2 interface. The MCE 130 is connected to an MME 120 via an M3 interface. The MCE 130 is a logical entity that may be standalone network node or may be part of another network node (e.g., an eNodeB 140 or MME 120). The MCE 130 handles admission control and the allocation of the radio resources used by all eNodeBs 140 in the Multicast-Broadcast Single Frequency Network (MBSFN) area for multi-cell MBMS transmission using MBSFN operation. The MCE 130 decides not to establish the radio bearer(s) of the new MBMS service(s) if the radio resources are not sufficient for the corresponding MBMS service(s) or may pre-empt radio resources from other radio bearer(s) of ongoing MBMS service(s) based on Allocation/Retention Priority (ARP). Besides allocation of the time/frequency radio resources, this also includes deciding the further details of the radio configuration, e.g., the modulation and coding scheme. The MCE 130 also performs the following functions:                Counting and acquisition of counting results for MBMS service(s);        Resumption of MBMS session(s) within MBSFN area(s) based on e.g. the ARP and/or the counting results for the corresponding MBMS service(s); and        Suspension of MBMS session(s) within MBSFN area(s) based e.g. the ARPand/or on the counting results for the corresponding MBMS service(s).        
The MCE 130 is involved in MBMS Session Control Signalling, but does not perform UE-MCE signalling. When the MCE 130 is part of another network element, an eNodeB 140 is served by a single MCE 130.
The MBMS GW 110 is also a logical entity. The MBMS GW 110 may be a standalone network node, or may be part of another network node. The MBMS GW 110 is present between the BM-SC 150 and eNodeB(s) 140, and its principal functions is the sending/broadcasting of MBMS packets to each eNodeB transmitting the service. The MBMS GW 110 uses IP Multicast as the means of forwarding MBMS user data to the eNodeB(s). The MBMS GW 110 performs MBMS Session Control Signalling (e.g., session start/stop) towards the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) via the MME 120.
Protocol Independent Multicast (PIM)-Source Specific Multicast (SSM) is the chosen multicast method in 3GPP. During establishment of an MBMS session, the MBMS GW will set a multicast source IP address (S), allocate a transport network multicast IP address (G), and send the multicast address distribution including S and G to the MCE and then to the eNodeB so that the eNodeB may join the addresses to enable reception of MBMS data.
Now the 3GPP signaling protocols for the interfaces including M1, M2 and M3 support only one type of IP multicast distribution address, either in IPv4 or IPv6. Therefore the broadcast/multicast can be done either through IPv4 or IPv6, in other words, the multicast distribution of eMBMS is applicable to only one type of network. However, some operators have not deployed pure IPv6 radio access networks or backhaul networks yet, e.g. they are still operating pure IPv4 networks, or hybrid networks of IPv4 and IPv6. This may cause some problems in applying the eMBMS. For instance, if some eNodeBs only support IPv4 while others support IPv6, then only part of the eNodeBs may join a multicast group since the multicast is done either through IPv4 or IPv6. Even if the eNodeBs support both IPv4 and IPv6, it is possible that the backhauls only support one type of IP addresses. In this case still only part of the eNodeBs may join the multicast group, unless additional routers are added and tunnels are setup for the multicast, which will complicate the backhaul network.